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REMARKS 

Applicant respectfully requests entry of the foregoing amendments and reconsideration of 
the merits of the outstanding rejections in view of the following remarks. Claims 1-54 are 
currently pending. 

I. Allowable Subject Matter 

Applicant notes with appreciation the indication on page 12 of the Office Action that 
claims 5, 6, 8, 13, 14, 17, 23, 24, 34, 35, 44, and 45 would be allowable if rewritten in 
independent form including all of the limitations of the base claim and any intervening claims. 

Claims 5, 6, 13, 17, and 23 have been amended in this manner, and accordingly these 
claims and all claims dependent therefrom, i.e., claims 14 and 24, should now be allowable. 
Acknowledgment of same is respectfully requested. 

Applicant has opted to defer rewriting claims 34, 35, 44, and 45 in independent form 
pending reconsideration of the arguments presented below with respect to the rejected 
independent claims. 

Dependent claim 8 has been amended to depend from dependent claim 7. 

II. The Anticipation Rejection of Claims 1-4 and 7 

Claims 1-4 and 7 stand rejected under 35 U.S.C. § 102(b), as allegedly anticipated by 
"AppShield Provides Block Against Application Hacks," Report on Electronic Commerce, BRP 
Publications (referred to as "the BRP Publication" within the Office Action). Applicant 
respectfully submits that this rejection is unsustainable. 

Applicant has amended independent claim 1 to include the limitation "designating an 
application path of an application as restricted," which was originally found in dependent claim 
20 and identified by the Examiner as not taught by the BRP Publication. See Office Action, page 
7, paragraph 22. Dependent claims 2-4 and 7 depend from claim 1. 

The Examiner is respectfully requested to withdraw the instant rejection of claims 1-4 

and 7. 

III. The Obviousness Rejection of Claims 9-12, 15, 16. 18-22. 25-33. and 46-54 

Claims 9-12, 15, 16, 18-22, 25-33, and 46-54 stand rejected under 35 U.S.C. § 103(a), as 
allegedly being unpatentable over the BRP Publication in view of U.S. Patent No. 6,584,569 to 
Reshef et al ("the '569 Patent"). Particularly, the Examiner contends that the BRP Publication 
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taken together with Reshef teaches or suggests all of the limitations recited in these claims. 
Applicant respectfully disagrees and traverses this rejection. 

As stated in MPEP § 2143, to establish a prima facie case of obviousness, three basic 
criteria must be met. First, there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art, to modify 
the reference or to combine reference teachings. Second, there must be a reasonable expectation 
of success. Finally, the prior art reference (or references when combined) must teach or suggest 
all the claim limitations. The teaching or suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the prior art, not in applicant's 
disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). Also, as stated in 
MPEP § 2143.01, obviousness can only be established by combining or modifying the teachings 
of the prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. 
Cir. 1988); In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). The mere fact that 
references can be combined or modified does not render the resultant combination obvious 
unless the prior art also suggests the desirability of the combination. In re Mills, 916 F.2d 680, 
16 USPQ2d 1430 (Fed. Cir. 1990). Further, as stated in MPEP § 2143.01, to establish prima 
facie obviousness of a claimed invention, all the claim limitations must be taught or suggested by 
the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974). That is, "[a]U words in a 
claim must be considered in judging the patentability of that claim against the prior art." In re 
Wilson, 424 F.2d 1382, 165 USPQ 494, 496 (CCPA 1970). Finally, if an independent claim is 
nonobvious under 35 U.S.C. 103, then any claim depending therefrom is nonobvious. In re Fine, 
837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). 

The BRP Publication vaguely describes an Internet application for security, referred to as 
"AppShield." See BRP Publication, lines 13-14. AppShield protects the integrity of an e- 
commerce application by making it nearly impossible for hackers to use traditional security 
loopholes, either in the applications code or within Web servers. Id. at lines 27-29. AppShield 
rejects unexpected - and therefore illegal - inputs, generating an error page for the user and 
notifying the AppShield management log. Id. at lines 30-32. 
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The '569 Patent is directed toward a system for determining web application 
vulnerabilities. See '569 Patent, abstract. Particularly, client requests and server responses 
resulting therefrom are analyzed in order to discover pre-defined elements of the application's 
interface with external clients and the attributes of these elements. Id. The client requests are 
then mutated based on a pre-defined set of mutation rules to thereby generate exploits unique to 
the application. Id. The web application is attacked using the exploits and the results of the 
attack are evaluated for anomalous application activity. Id. Broadly speaking, the '569 Patent's 
technique for identifying application vulnerabilities is not relevant to Applicant's invention 
which is broadly directed to preventing exploitation of application vulnerabilities. 

Now referring to particular claims, the BRP Publication taken in combination with the 
'569 Patent fails to teach or suggest "designating an application path of an application as 
restricted" as recited in currently amended independent claim 1 and originally found in 
dependent claim 20. Although such a limitation is acknowledged as not taught by the BRP 
Publication, the Examiner asserts that this deficiency is cured by the '569 Patent and "[it] would 
have been obvious to one of ordinary skill in the art at the time of the invention to include the 
application path of the application restricted [sic] with BRP publications [sic], the motivation is 
that the detection phase searches for application path parameters in order to check for a 
vulnerability." Office Action, page 7, paragraph 22. Applicant respectfully disagrees. 

As a preliminary matter, the Examiner's statement "to include the application path of the 
application restricted with BRP publications . . ." is ambiguous and fails to properly convey the 
Examiner's reasoning to support a conclusion of obvious subject matter. Moreover, even the 
inclusion of the purported obvious subject matter (i.e., an application path) does not fully address 
nor even reach the entire scope of the claimed invention as the claimed invention expressly 
recites the step of " designating an application path of an application as restricted ." Emphasis 
added. The Examiner's support fails to specifically address why it would have been obvious to 
include within AppShield an additional step of designating an application path as restricted. 

Contrary to the Examiner's contention, the '569 Patent does not teach or suggest 
"designating an application path of an application as restricted." As noted above, the '569 Patent 
is concerned with discovering vulnerabilities not preventing the exploitation thereof. No 
disclosure within the '569 Patent discusses restricting certain application paths of an application. 
The passages cited by the Examiner describe mutating data and path parameters according to 
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pre-defined vulnerability detection rules to discover vulnerabilities. See '569 Patent, col. 8, lines 
61-67 and col. 9, lines 1-3 and 31-53. Clearly, one of ordinary skill in the art does not equate the 
'569 Patent's step of mutating path parameters to the claimed step of designating an application 
path as restricted. Accordingly, the '569 Patent fails to cure the deficiency noted with respect to 
the BRP Publication. Because all the claim limitations are not taught or suggested by the prior 
art, amended independent claim 1 is nonobvious. 

With respect to independent claim 27, the Examiner asserts on page 9 of the Office 

Action: 

As per claim 27, BRP publications does not teach the following 
limitations; however [sic], Reshef et al. discloses a system for implement [sic] an 
application security layer between a trusted application and a distrusted computer 
environments including: means for receiving an operation request (see col. 3, 
lines 44-58) for said application; means for embedding said operation request into 
a data format used by said trusted application (see col. 3, lines 60-67, col. 4, lines 
1-8) an encoder for encoding said operation request according to an encoding 
scheme; and means for applying a pipe to each operation request, wherein the 
number and types of pipes applied to each operation request are based on said 
resolved destination node of each operation request (see col. 4, lines 1-30). It 
would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine BRP with Reshef, both teaches protecting an application 
from hackers, the motivation to protect application from hackers is that a hacker 
can alter a parameter in an http request, and freeze the application (see col. 4, 
lines 1-8). 

Such reasoning fails to establish prima facie obviousness of claim 27. 

First, the Examiner's reasoning fails to convey a logical premise from which Applicant 
can respond. Particularly, no particular claim limitations are identified as missing from the BRP 
publication even though it is acknowledged that the BRP publication "does not teach the 
following limitations." The Examiner fails to identify any "following" limitations. Moreover, 
the limitations "means for receiving . . means for embedding . . ., an encoder . . .," which the 
Examiner contends are taught by the '569 Patent are not even recited in the claim at issue. Claim 
27 recites a method with certain steps, not a means-plus-function apparatus or system claim. 

Second, the motivation for combining the '569 Patent with the BRP Publication is 
unsoundly based. Particularly, the Examiner contends that "[i]t would have been obvious to one 
of ordinary skill in the art at the time of the invention to combine BRP with Reshef, both teaches 
protecting an application from hackers, the motivation to protect application from hackers is that 
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a hacker can alter a parameter in an http request, and freeze the application (see col. 4, lines 1-8). 

Applicant submits that such a statement does not make logical sense. Moreover, as noted above, 

the '569 Patent subject matter does not protect an application from hackers, it merely mimics 

what a hacker might do in an attempt to discover vulnerabilities in security. Furthermore, as the 

noted case law clearly requires, there must be some suggestion or motivation to combine 

reference teachings. The Examiner's noted motivation "to protect [an] application from hackers" 

is irrelevant and fails to address why one of ordinary skill in the art would be motivated to 

combine the BRP Publication with the alleged teachings of ' 569 Patent. 

Third, the BRP Publication taken in combination with the '569 Patent fails to teach or 

suggest "resolving a destination node for each operation request; and applying one or more 

security pipes to each operation request, wherein the number and types of pipes applied to each 

operation request are based on said resolved destination node of each operation request" as 

claimed. Exemplary support for this claim language is found at page 14, line 5, of Applicant's 

Specification, which states: 

Upon successful identification of the destination of the distrusted message, 
one or more pipes are applied serially (steps 350-355) to the message to 
intensively scrutinize the message contents, e.g., instructions, commands, URI, 
query string, environmental variables, and parameters contained within the 
request, thereby, further insuring that the request is legal and harmless. 

* * * * 

Each pipe provides a different type of specific security protection or monitoring 
functionality. The number of pipes is dependent on the amount of security 
deemed necessary, based on the type and needs of each tunnel and/or application 
path. For example, one tunnel may have three pipes applied, while another tunnel 
may only have two applied. 

Different pipes act as different security components. For example, a first pipe protects against 

known application vulnerabilities, a second prevents database manipulations, and a third 

prevents parameters poisoning. Applicant's Specification, page 11, lines 26-28. Hence, 

different sets of security components can be applied to different operation requests based upon 

the intended destination node of the operation requests. As noted above, the BRP Publication 

provides no specifics as to how AppShield actually blocks application hacks and the '569 Patent 

is merely concerned with discovering vulnerabilities, i.e., possible ways to hack into an 

application, and not with preventing hackers from using such vulnerabilities. Neither reference 
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teaches or suggests applying a particular set of security pipes to an operation request based on a 
resolved destination node of the operation request as claimed. 

The remaining independent claims (i.e., claims 48 and 51) recite related subject matter to 
the above-identified independent claims, and are therefore allowable for reasons similar to those 
given above. 

The dependent claims are allowable at least by virtue of their dependency on the above- 
identified independent claims. Moreover, these claims recite additional subject matter which is 
not suggested by the references taken either alone or in combination. For instance, claim 7 
recites "checking said operation request for an existence of an embedded command causing 
database manipulation." The BRP Publication and the '569 Patent both fail to account for 
database manipulation attacks, particularly attacks in the form of embedded SQL commands (see 
claim 8). 

Moreover, claims 9 and 30 recite "parsing said operation request into one or more 
expressions; building a state-automate; inspecting said one or more expressions for improper 
syntax and characters not defined in a first alphabet; and applying said state-automate to said 
operation request." Although the '569 Patent describes a parsing engine 16, it merely parses 
outgoing replies and not incoming operation requests as claimed. 

Furthermore, claims 15 and 36 recite "dividing said operation request into four zones; 
comparing each of said four zones against stored known vulnerability patterns to determine a 
match . . . ." The BRP Publication and the '569 Patent neither teach or suggest inspecting four 
separate zones of an operation request against known vulnerability patterns. 

Claims 25 and 46 recite "computing an acceptable range of values for each parameter 
based on a statistical model applied to said dynamic range of entered values for each value . . . 
Support for this limitation is found in the "Learning" pipe described on page 28 of Applicant's 
Specification. Both the BRP Publication and the '569 Patent do not teach or suggest a learning 
technique that allows the parameters in a request to be "fine tuned" to better match the most 
common values entered by the clients, i.e., requestors, determined from a statistical model. See 
Applicant's Specification, page 8, lines 5-7. 

For at least the reasons set forth above, Applicant submits that the instant rejection of 
independent claims 9-12, 15, 16, 18-22, 25-33, and 46-54 is unsustainable. The Examiner is 
respectfully requested to withdraw the instant rejection of these claims. 



Page 19 of 20 



Application No. 09/809,030 

Reply dated January 1 1 , 2005 

Reply to Final Office Action of October 1 , 2004 

IV. Conclusion 

In view of the foregoing, it is respectfully submitted that the present application is in 
condition for allowance, and an early indication of the same is courteously solicited. The 
Examiner is respectfully requested to contact the undersigned by telephone at the below listed 
telephone number, in order to expedite resolution of any issues and to expedite passage of the 
present application to issue, if any comments, questions, or suggestions arise in connection with 
the present application. 

Please charge any shortage in fees due in connection with the filing of this paper or to 
maintain the instant application as pending, including extension of time fees, to Deposit Account 
No. 50-0206, and please credit any excess fees to the same deposit account. 



Intellectual Property Department 
1900 K Street, N.W., Suite 1200 
Washington, DC 20006-1109 
(202) 955-1500 (telephone) 
(202) 778-2201 (facsimile) 

TQCxdh 




Respectfully submitted, 
HUNTQN & WILLIAMS LLP 



Dated: January 11, 2005 



By: 



Hunton & Williams LLP 
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